feat(ci): replace release-please with git-cliff - #774

release-please collects commits by walking history in commit-date order and
stopping at the sha of the last release. That boundary holds with squash
merges, since main is linear, but not with merge commits. The v0.3.0 notes we
shipped show what it costs: 64 feat/fix entries for 36 merged PRs, the same
change listed twice, and #729 and #713 with no PR link at all.

git-cliff asks git for a real tag range instead, so commit dates cannot move
the boundary. Notes are built from the merge commits on main and everything on
the branch side is dropped, which is what stops every WIP commit inside a PR
appearing next to the PR itself. Replaying v0.3.0-rc2..v0.3.0 through this
config gives 12 features and 24 bug fixes against the 12 feat and 24 fix PRs
that actually merged.

Releases are cut by dispatching this workflow. It computes the version,
renders the notes, creates the tag and opens a draft; publishing the draft
stays a separate human decision and still fires docker, helm and docs through
`release: published`. Nothing writes to main, so the GitHub App, the
RELEASE_PLEASE_APP_ID and _PRIVATE_KEY credentials and the "allow Actions to
create and approve pull requests" setting are all unused now and can be
revoked.

The non-obvious parts, each of which is there for a verified reason:

- `--use-branch-tags`, because git-cliff otherwise takes the newest tag in the
  repository even when it is not an ancestor of HEAD. A stray v0.9.9 on an
  unmerged branch makes main report previous=v0.9.9 and silently shifts the
  notes range.
- the default-branch guard, because dispatching from a feature branch would
  tag and sign unreviewed code and leave exactly that stray tag.
- two content guards, because a commit only reaches the notes if it is a merge
  AND its subject parses as conventional. GitHub's default
  "Merge pull request #1 from ..." subject satisfies neither the eye nor the
  parser and used to vanish without a trace.
- the releasable-commits guard, because `no_increment_regex` is a no-op in
  git-cliff 2.13.1. The example from its own docs, a lone chore after 0.1.0
  documented to stay at 0.1.0, returns 0.1.1.
- `protect_breaking_commits` with the merge filter moved into the template, so
  a branch-side `feat!` still drives the bump when the PR title dropped the
  "!" without also rendering a duplicate section with no PR link.
- `--prerelease` for versions containing a hyphen, so an rc does not publish
  as a normal release and take over the Latest marker.
- the cliff.toml existence check, because a missing config makes git-cliff
  warn, exit 0 and fall back to its own defaults, which bump a breaking change
  straight to 1.0.0.

The asset build is unchanged from the release-please workflow it came from and
runs as a second job. `retry_assets_for` re-runs just that job against an
existing draft when an upload failed.

"v[0-9].*" matches any tag that merely contains v<digit>, so a foreign tag
like chart-v1.2.3 would become the changelog boundary and leak its prefix
into the computed version. Anchor it to the same shape the release workflow
validates.

A commit that lands on main without being a merge, or as a merge whose subject
is not conventional, blocks every release until the history is fixed. On a
protected main that means rewriting published history, which is worse than the
problem.

The guard now collects both cases and reports them together, and `force`
downgrades it to a warning so a release can go out without those commits in
the notes. They are still in the repository, so the draft can mention them by
hand before publishing.

Scoped deliberately: force does not skip the default-branch check, the
pending-draft check, or the releasable-commits check. Those are about whether
a release should happen at all, not about what the notes can represent.

The prerequisite named one of the three UI options rather than the requirement.
What matters is that the merge commit title comes from the PR title, which both
'Pull request title' and 'Pull request title and description' do. Only 'Default
message' breaks the notes.

sha256sum wrote bin/-prefixed paths, so a user who downloads the flat assets
and runs `sha256sum -c checksums.txt` gets 'No such file or directory' for
every entry. Carried over unchanged from the release-please workflow.

Also names the setting behind the pre-1.0 breaking policy in the docs, so it
does not read as something safe to delete.